VTC systems must be logically or physically segregated on the LAN from data systems, other non-integrated voice communication (VoIP) systems, and by VTC system type.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-17713	RTS-VTC 4120.00	SV-18887r2_rule	DCPB-1 DCSP-1 ECSC-1	Medium

Description
A common and widely used practice in traditional LAN design is the use and implementation of VLANs (at layer 2) and IP subnets (at layer 3) to segregate services and organizational workgroups or departments, including their traffic as it traverses the LAN. This has the effect of providing confidentiality for the workgroup traffic by limiting the ability of users in other workgroups to see and access the traffic during normal operations. It also enhances the ability to control traffic flows for, and access to, LAN services. Another benefit of using VLANs is that they can improve network performance if they are properly pruned. Typically, when a VLAN is configured on one LAN switch, the other switches in the network will “learn” that VLAN, thus it will propagate throughout the network. This property is not what enhances network performance since it allows broadcast traffic in the VLAN to traverse the entire network. Also, if the number of allowable VLANs that a switch has configured or learns is exceeded, the LAN can become unstable. VLAN pruning eliminates this problem and is actually what can enhance network performance by limiting the traffic that devices in the LAN must process. This practice is very useful in protecting a communications service running on the LAN. The use of a separate IP address space and separate VLANs for VoIP telephone systems (different than those assigned to data services) is required by the VoIP STIG. This requirement helps protect the voice communication service from compromise and will provide the same protection for VTC services running on the LAN. The use of a separate IP address space and properly pruned separate VLANs for VTC systems will have the following effects: • Enhance the confidentiality of unencrypted VTC traffic. • Enhance the confidentiality of the VTC device management traffic, particularly if secure protocols are not available for use. • Limit the ability of the average LAN user (in the data VLAN(s)) to “see” the VTC device(s) on the LAN (in the VTC VLAN(s)), thereby limiting the possibility of compromise from user- or machine-induced malicious activity (in data VLAN(s)). Note: This separation is intended to protect the VTC devices and the information conveyed by them from compromise. It is not intended to prevent a PC soft VTC client (in the data VLAN(s)) from participating in a conference or from viewing a streamed conference. This can be implemented through appropriate routing and gateways. Different VTC systems should be protected using different VLAN structures as follows: • Primary conference room systems should have their own closely pruned VLAN and IP subnet. This could be a single conference room or several conference rooms if they are required to communicate with each other or are part of an overall managed VTC network within the enclave. This will provide the maximum protection from compromise for the conference room systems. • Hardware-based desktop and office VTUs should be grouped into their own VLAN and IP subnet. This could be the same VLAN and subnet as the one used for conference rooms if these devices are to communicate with them or if they are part of an overall managed VTC network within the enclave. • Hardware-based desktop and office VTUs that integrate and signal with the site’s VoIP telephone system may be grouped separately or utilize the Voice system VLAN structure and IP subnet. • PC-based soft-VTUs are to be implemented or segregated/controlled as described in the related document covering softphones and soft-VTUs. • Local MCUs and VTU management stations must reside in the VTC VLAN and IP subnet with the devices they manage or conference. • If WAN access is required, the VLAN(s) can be extended to the enclave boundary. Another concern when implementing VLANs on a LAN is the default functionality of routers to create paths or routes between IP addresses that they can reach or are aware of. While it requires a routing device (router or a layer three switch) to communicate between VLANs, a router will, by default, create a route between the IP addresses in the different VLANs it “sees”. This behavior works against the separation and protection provided by a segregated VLAN and IP subnet structure. To maintain the integrity of this structure, router ACLs must be configured on routing devices that block this default behavior. VTU traffic is then only permitted to cross VLAN boundaries where required and at the points in the LAN where required. Note: VLAN pruning must limit the reach of the VLAN(s) to only those network elements and links required to interconnect the devices in the VLAN. This requirement is supported by DoDI 8500.2 IA control DCSP-1 regarding Security Design and Configuration/Security Support Structure Partitioning which states: “The security support structure is isolated by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions. The security support structure maintains separate execution domains (e.g., address spaces) for each executing process.” Note: While separate IP subnets and VLANs closed by ACLs do provide the benefits noted above, they are not in and of themselves a security mechanism. The security benefit is derived from the behavior of VLANs configured in this manner. Additionally, it is known that the separation of VLANs can be overcome by specialized software which sometimes relies on an improperly configured LAN. Such software typically requires the attacker to have physical access to the LAN containing the VLANs. This in no way negates the benefit derived from using separate IP subnets and “closed” VLANs for the protection and benefit of VoIP and VTC systems.

Description

A common and widely used practice in traditional LAN design is the use and implementation of VLANs (at layer 2) and IP subnets (at layer 3) to segregate services and organizational workgroups or departments, including their traffic as it traverses the LAN. This has the effect of providing confidentiality for the workgroup traffic by limiting the ability of users in other workgroups to see and access the traffic during normal operations. It also enhances the ability to control traffic flows for, and access to, LAN services. Another benefit of using VLANs is that they can improve network performance if they are properly pruned. Typically, when a VLAN is configured on one LAN switch, the other switches in the network will “learn” that VLAN, thus it will propagate throughout the network. This property is not what enhances network performance since it allows broadcast traffic in the VLAN to traverse the entire network. Also, if the number of allowable VLANs that a switch has configured or learns is exceeded, the LAN can become unstable. VLAN pruning eliminates this problem and is actually what can enhance network performance by limiting the traffic that devices in the LAN must process. This practice is very useful in protecting a communications service running on the LAN. The use of a separate IP address space and separate VLANs for VoIP telephone systems (different than those assigned to data services) is required by the VoIP STIG. This requirement helps protect the voice communication service from compromise and will provide the same protection for VTC services running on the LAN. The use of a separate IP address space and properly pruned separate VLANs for VTC systems will have the following effects: • Enhance the confidentiality of unencrypted VTC traffic. • Enhance the confidentiality of the VTC device management traffic, particularly if secure protocols are not available for use. • Limit the ability of the average LAN user (in the data VLAN(s)) to “see” the VTC device(s) on the LAN (in the VTC VLAN(s)), thereby limiting the possibility of compromise from user- or machine-induced malicious activity (in data VLAN(s)). Note: This separation is intended to protect the VTC devices and the information conveyed by them from compromise. It is not intended to prevent a PC soft VTC client (in the data VLAN(s)) from participating in a conference or from viewing a streamed conference. This can be implemented through appropriate routing and gateways. Different VTC systems should be protected using different VLAN structures as follows: • Primary conference room systems should have their own closely pruned VLAN and IP subnet. This could be a single conference room or several conference rooms if they are required to communicate with each other or are part of an overall managed VTC network within the enclave. This will provide the maximum protection from compromise for the conference room systems. • Hardware-based desktop and office VTUs should be grouped into their own VLAN and IP subnet. This could be the same VLAN and subnet as the one used for conference rooms if these devices are to communicate with them or if they are part of an overall managed VTC network within the enclave. • Hardware-based desktop and office VTUs that integrate and signal with the site’s VoIP telephone system may be grouped separately or utilize the Voice system VLAN structure and IP subnet. • PC-based soft-VTUs are to be implemented or segregated/controlled as described in the related document covering softphones and soft-VTUs. • Local MCUs and VTU management stations must reside in the VTC VLAN and IP subnet with the devices they manage or conference. • If WAN access is required, the VLAN(s) can be extended to the enclave boundary. Another concern when implementing VLANs on a LAN is the default functionality of routers to create paths or routes between IP addresses that they can reach or are aware of. While it requires a routing device (router or a layer three switch) to communicate between VLANs, a router will, by default, create a route between the IP addresses in the different VLANs it “sees”. This behavior works against the separation and protection provided by a segregated VLAN and IP subnet structure. To maintain the integrity of this structure, router ACLs must be configured on routing devices that block this default behavior. VTU traffic is then only permitted to cross VLAN boundaries where required and at the points in the LAN where required. Note: VLAN pruning must limit the reach of the VLAN(s) to only those network elements and links required to interconnect the devices in the VLAN. This requirement is supported by DoDI 8500.2 IA control DCSP-1 regarding Security Design and Configuration/Security Support Structure Partitioning which states: “The security support structure is isolated by means of partitions, domains, etc., including control of access to, and integrity of, hardware, software, and firmware that perform security functions. The security support structure maintains separate execution domains (e.g., address spaces) for each executing process.” Note: While separate IP subnets and VLANs closed by ACLs do provide the benefits noted above, they are not in and of themselves a security mechanism. The security benefit is derived from the behavior of VLANs configured in this manner. Additionally, it is known that the separation of VLANs can be overcome by specialized software which sometimes relies on an improperly configured LAN. Such software typically requires the attacker to have physical access to the LAN containing the VLANs. This in no way negates the benefit derived from using separate IP subnets and “closed” VLANs for the protection and benefit of VoIP and VTC systems.

STIG	Date
Video Services Policy STIG	2015-02-05

Details

Check Text ( C-49195r8_chk )
Review network diagrams and router/switch configurations to verify the VTC system(s) within the enclave is (are) separated from the rest of the data network as follows: • Verify that there is a dedicated LAN infrastructure and IP address space for the VTC endpoints. OR • Verify that there is a pruned and closed VLAN/IP subnet structure and dedicated IP address space on the LAN for the VTC system(s) that is (are) separate from the VLAN and IP address space/IP subnet structure(s) assigned to data systems and other non-integrated voice communications (VoIP) systems. • Verify that VTC systems are segregated on the LAN from themselves and other LAN services as follows: - Primary conference room systems - Hardware-based desktop and office VTUs Exception 1: If integrated with the VoIP phone system (i.e., signals with the local call controller), these devices may connect to the VoIP system VLAN structure. Exception 2: If part of an overall managed VTC network within the enclave and/or hardware-based desktop and office VTUs must communicate with the conference room systems within the enclave, these devices may connect to the conference room VLAN structure. • Local MCUs and VTU configuration management/control servers must reside in the VTC VLAN and IP subnet with the devices they manage or conference. • If WAN access is required, the VLAN(s) or dedicated infrastructure can be extended to the enclave boundary. If any of these criteria apply and are not implemented, this is a finding.

Check Text ( C-49195r8_chk )

Review network diagrams and router/switch configurations to verify the VTC system(s) within the enclave is (are) separated from the rest of the data network as follows:
• Verify that there is a dedicated LAN infrastructure and IP address space for the VTC endpoints.
OR
• Verify that there is a pruned and closed VLAN/IP subnet structure and dedicated IP address space on the LAN for the VTC system(s) that is (are) separate from the VLAN and IP address space/IP subnet structure(s) assigned to data systems and other non-integrated voice communications (VoIP) systems.
• Verify that VTC systems are segregated on the LAN from themselves and other LAN services as follows:
- Primary conference room systems
- Hardware-based desktop and office VTUs
Exception 1: If integrated with the VoIP phone system (i.e., signals with the local call controller), these devices may connect to the VoIP system VLAN structure.
Exception 2: If part of an overall managed VTC network within the enclave and/or hardware-based desktop and office VTUs must communicate with the conference room systems within the enclave, these devices may connect to the conference room VLAN structure.
• Local MCUs and VTU configuration management/control servers must reside in the VTC VLAN and IP subnet with the devices they manage or conference.
• If WAN access is required, the VLAN(s) or dedicated infrastructure can be extended to the enclave boundary.
If any of these criteria apply and are not implemented, this is a finding.

Fix Text (F-48631r5_fix)
Perform the following tasks: Implement a dedicated LAN infrastructure and IP address space for the VTC endpoints or implement a pruned and closed VLAN that is separate from the VLAN assigned to data systems and other non-integrated voice communications (VoIP) systems. Implement a separate IP address subnet for the VTC system(s) separate from the IP address subnet assigned to data systems and other non-integrated voice communications (VoIP) systems. Configure Access Control Lists on each routing device in the LAN to limit traffic that needs to cross between the VTC VLANs and the data or management VLAN to authorized traffic based on the service or authorized IP address.

Fix Text (F-48631r5_fix)

Perform the following tasks:
Implement a dedicated LAN infrastructure and IP address space for the VTC endpoints or implement a pruned and closed VLAN that is separate from the VLAN assigned to data systems and other non-integrated voice communications (VoIP) systems.

Implement a separate IP address subnet for the VTC system(s) separate from the IP address subnet assigned to data systems and other non-integrated voice communications (VoIP) systems.

Configure Access Control Lists on each routing device in the LAN to limit traffic that needs to cross between the VTC VLANs and the data or management VLAN to authorized traffic based on the service or authorized IP address.